崩溃机制


当NW.js崩溃时 , 将在桌面创建名为minidump(.dmp)文件 . 该文件中包括问题报告信息 , 通过解码minidump文件获取崩溃时的异常信息 . 这样能够查找到NW.js崩溃的原因 .

minidump文件中提取出的异常信息过程 , 需要利用三个条件: 崩溃时产生的minidump(.dmp)文件 , NW.js的符文件以及minidump_stackwalk工具 .

获取minidump文件

NW.js崩溃时在不同系统中生成minidump的路径:

  • Linux: ~/.config/<name-in-manifest>/Crash\ Reports/
  • Windows: %LOCALAPPDATA%\CrashPad
  • Mac: ~/Library/Application\ Support/<name-in-manifest>/CrashPad/

<name-in=manifest>配置文件name属性 .

注 , Linux系统中生成的minidump文件会附带头文本信息 , 该部分信息在解码之前需要删除 , 真正minidump文件内容由`MDMP`开始 , 之前的内容是不可读的 , 可以直接删除 .

整理条码文件

NW.js释放包中的条码文件在NW.js下载目录的同名目录中 . 条码文件(.sym)能够从下载包中提取 .

整理条码文件需要使用minidump_stackwalk工具在正确的路径中与正确的文件名进行 . minidump_stackwalk使用简单条码供应商获取条码文件 . 以下步骤展示如何查找条码文件 .

工具将以下模式尝试查找.sym文件: {SYMBOLS_ROOT}/{DEBUG_FILE_NAME}/{DEBUG_IDENTIFIER}/{DEBUG_FILE_NAME_WITHOUT_PDB}.sym

  • {SYMBOLS_ROOT}是所有条码文件的根目录 . NW.js所有版本或者使用系统都可以将.sym文件放入该目录中 .
  • {DEBUG_FILE_NAME}, {DEBUG_IDENTIFIER}{DEBUG_FILE_NAME_WITHOUT_PDB}作为.sym文件的第一行 , 例如MODULE Linux x86_64 265BDB6BE043D5C70D3A1E279A8F0B1A0 nw
    • 265BDB6BE043D5C70D3A1E279A8F0B1A0对应{DEBUG_IDENTIFIER}
    • nw对应{DEBUG_FILE_NAME}.
    • {DEBUG_FILE_NAME_WITHOUT_PDB}能够覆盖删除.pdb{DEBUG_FILE_NAME} , 该方式只有在Windows系统中需要 .

Minidump解码

minidump_stackwalk能够使用NW.js构建 . Linux和Mac系统的报告器代码中直接构建 . Windows系统中使用Cygwin预制构建 .

运行以下命令从minidump获取异常信息:

minidump_stackwalk minidump_file.dmp /path/to/symbols_root 2>&1

如果条目文件不能正确整理 , 仍然可以使用该工具获取 . 但不能查看 , 最后部分会输出一下警告信息:

0x00240000 - 0x02b29fff nw.exe ??? (main) (WARNING: No symbols, nw.exe.pdb, 669008F7B6EE44058CBD5F21BEB5B5CFe)

触发崩溃以测试

测试崩溃机制特性 , NW.js提供APIs触发崩溃: App.crashBrowser()App.crashRenderer() . 分别是崩溃浏览器进程和渲染进程 .

参考

  • http://www.chromium.org/developers/decoding-crash-dumps
  • http://code.google.com/p/google-breakpad/wiki/GettingStartedWithBreakpad